Description

• Refactored the upload progress logic to clarify the conceptual hierarchy between steps, stages, and the overall upload process (mainly in the use-upload-progress hook and components)
• The goal was to make the data model, naming, and types more expressive and consistent across the codebase — improving readability, type safety, and maintainability.

Key Changes

1. Clarified the data model

• Step → the smallest unit of work (creating-car, announcing-cids, etc.)

• Stage → a logical grouping of one or more steps
  (e.g., first stage = creating-car, checking-readiness, uploading-car)

• Upload → the complete process made up of all stages

Defined explicit StepState, StageState, and UploadState types to reflect this structure.

2. Split types into modular files

• Moved upload-related types and util functions into a dedicated src/types/upload/ and src/utils/upload/ directory:

3. Renamed ambiguous variables and functions

• progresses → stepStates to reflect that these hold full step state objects, not just progress values.

• calculateCompletionStates → getUploadOutcome for clearer intent.

• getStageBadgeStatus → getUploadBadgeStatus since the badge reflects overall upload state, not an individual stage.

4. Added explicit badge-status logic to reflect publishing progress more accurately:

In progress - During:

• 'creating-car' in progress
• 'uploading-car' in progress
• 'checking-readiness' in progress
• 'announcing-cids' in progress
• 'finalizing-transaction' in progress

Published - When:

• 'finalizing-transaction' is completed BUT 'announcing-cids' is not yet completed

Pinned - When:

• Both 'finalizing-transaction' AND 'announcing-cids' are completed